REMARKS 



Claims 1-2, 6-20, and 24-27 have been amended. Claims 1-27 remain pending in 
the application. Reconsideration is respectfully requested in light of the following 
remarks. 

Section 101 Rejection : 

The Office Action rejected claims 10-18 under 35 U.S.C. § 101 because the 
claimed invention is allegedly directed to non- statutory subject matter. Applicant 
respectfully traverses this rejection. However, in order to expedite prosecution, these 
claims have been amended to recite a non-transitory computer-readable storage medium, 
as suggested by the Examiner. For at least this reason. Applicant requests removal of the 
rejection of claims 10-18 under 35 U.S.C. § 101. 

Section 103fa) Rejections : 

The Examiner rejected claims 1, 2, 4, 5, 7, 9, 10, 11, 13, 14, 16, 18-20, 22, 23, 25 
and 27 under 35 U.S.C. § 103(a) as being unpatentable over Patel et al. (U.S. Patent 
6,865,185) (hereinafter "Patel") in view of Win et al. (U.S. Patent 6,453,353) (hereinafter 
"Win") and further in view of Lupu, et al. ("Use of Roles and Policies for Specifying and 
Managing a virtual Enterprise") (hereinafter "Lupu"), claims 3, 12 and 21 as being 
unpatentable over Patel, Win and Lupu and further in view of Ayyagari et al. (U.S. 
Publication 2001/0024434) (hereinafter "Ayyagari"), claims 6, 15 and 24 as being 
unpatentable over Patel, Win and Lupu in view of Zara et al. (U.S. Patent 7,206,848) 
(hereinafter "Zara"), claims 8, 17 and 26 as being unpatentable over Patel, Win and Lupu 
in view of Vange (U.S. Publication 2002/0059170). Applicant respectfully traverses this 
rejection for at least the following reasons. 

Regarding claim 1 , the cited art fails to teach or suggest a server system receiving 
a request for service from a client, wherein said request includes an encoding specifying 
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a current user role and a requested service and in response to receiving the request for 
service... establishing a quality of service context based on the specified current user role 
included in said request and based on said policy data. The Examiner admits that Patel 
does not disclose a server system receiving a request that includes a current user role, and 
relies on Win to teach this aspect of Applicant's claim. The Examiner further admits that 
Patel does not disclose establishing a quality of service context based on the current user 
role, and relies on Win and Lupu to teach this aspect of Applicant's claim. 

Patel is directed to a system and method for queuing traffic in a wireless 
communication network. In Patel, packets for transmission include a flow identifier. The 
packets are assigned to one of a plurality of virtual groups that include discrete 
transmission resources based on a variety of parameters, including the flow identifier. 
Win is directed to role-based navigation of information resources (e.g., information 
resources stored on a protected Web server). In Win, user roles (described in Win as "job 
functions") are used in determining what resources a user can access, not in establishing a 
quality of service context. The Examiner relies on Win to disclose a request that includes 
a current user role. Specifically, the Examiner cites column 6, lines 44-48 and 58-65, as 
teaching, "user sending a request with a cookie identifying the user roles to the server." 
This and other passages of Win describe that when a user logs into the system (e.g., by 
logging into an access server using a single sign-on), the user is first authenticated (e.g., 
using the user's name and password), and then another module of the access server reads 
the user's roles (plural) from a Registry Server , encrypts them, and sends this information 
in a "roles cookie" to the user's browser. In other words, in Win, a roles cookie is 
created by the access server in response to a user login, based on information about the 
user's roles that is stored in the Registry Server, and then this roles cookie is sent to the 
user's browser. This roles cookie is not an encoding specifying a current user role, but is 
described as containing "a list of the user's roles" (see, e.g., column 10, line 55). There is 
nothing in Win that describes or implies that the roles cookie specifies which of the 
user's roles is a current user role. Since the roles cookie taught by Win does not specify a 
current user role , but contains a list of users roles , it cannot be used to establish a QoS 
context based on the specified current user role . 
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The Examiner submits that it would have been obvious to one of ordinary skill in 
the art to have modified Patel's service requests to include a current user role as taught by 
Win, stating, "Such a modification is an example of simple substitution of one known 
element (Win's user request that contains a role cookie) for another (Patel's user request) 
to obtain predictable results (Patel's system modified to directly receive user roles to 
identify which policies to apply to the request, see Win, column 5 «Iines 44-54»)." 
The Examiner's suggested "predictable result" appears to be that extraneous (and 
unnecessary) information would be included in the packets transmitted by Patel, since 
Patel's system does not rely on user roles for any of its functionality, much less for 
establishing a quality of service context. Instead, Patel uses completely different types of 
information to determine quality of service parameters for received packets. 

The Examiner admits that Patel and Win do not expressly disclose establishing a 
quality of service context based on the current user role, and relies on Lupu to teach this 
aspect of Applicant's claim. Specifically, the Examiner submits that Lupu discloses the 
use of the user role to estabhsh particular QoS restraints (e.g., requirements, capabilities, 
contracts in terms of error rates, throughputs, delay, etc.) on the user's action, citing 
Lupu, page 1, paragraph 1: Introduction, and page 2, paragraph 2.1: ODP Definition of a 
role: "A role type. . . may include additional constraints on the behavior, such as policy or 
Quality of Service (QoS) statements ". Lupu is directed to the use of roles and policies 
(e.g., rights and duties associated with an organizational position) for specifying and 
managing a virtual enterprise, and has nothing to do with the limitations of 
Applicant's claim. For example, the Examiner's citation on page 2 of Lupu does not 
describe the handling of a service request in a virtual enterprise, much less the use of a 
user role in establishing a QoS context for a request for service made in (or received by) 
such a virtual enterprise. Instead, the cited passage is actually a description of some of 
the concepts of the ODP enterprise language that can be used to define and model 
behavior in a virtual enterprise. In the ODP enterprise language, a "role" is a foundation 
concept that can be used to define the rights, responsibilities, and/or behavior of various 
components (objects) of a virtual enterprise. The objects are agents (actors) in the system 
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(human or otherwise). As noted above, a "role type" definition may include QoS 
statements. However, nothing in Lupu describes establishing a QoS context for a request 
for service in a virtual enterprise. 

Lupu is not directed to establishing QoS context for a request for service, but for 
defining and using role types to model the behavior of agents in a virtual enterprise. It is 
not clear how the Examiner means to combine the references in teaching Applicant's 
claim. For example, the roles cookie taught by Win does not specify a current user role , 
but contains a list of user roles . Therefore, even if Lupu taught the use of a current user 
role in establishing a QoS for a request for service (which it does not) the roles cookie of 
Win would not specify a current user role (or role type) with which to establish a QoS 
context. Instead, each of the user roles listed in the roles cookie of Win would (according 
to Lupu) be defined using a different role type definition, and could include different QoS 
statements. In other words, the roles cookie of Win does not specify which of a list of 
user roles for a given user is the current role , and thus could not be used to map a current 
user role to a role type definition that includes QoS statements. Therefore, even if there 
were some way to combine the teachings of Patel, Win, and Lupu, their combination 
would not result in Applicant's claimed invention. 

The Examiner submits, "It would have been obvious to one of ordinary skill in the 
art to have modified Patel's QoS system to include the user role functionality described 
above from Win and Lupu. Such a modification would have provided improvement to 
Patel's system because incorporating role-based QoS (as taught in Win and Lupu) 
provides a more fiexible and extensible way to control QoS in a network [see for example 
Win, abstract | column 2 «Iines 26-28»: the user role allows fiexibility and 
extensibility in adding users to the system]." The Examiner's own citation and remarks 
do not support his conclusions. Win's abstract does not describe such an advantage of 
role-base QoS, but states, "The registry server controls a flexible, extensible, additive 
data model stored in a database that describes the user, the resources, roles of the user, 
and functional groups in the enterprise that are associated with the user." In other words, 
Win's abstract describes the use (and advantage to the system of Win) of a flexible. 
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extensible, and additive data model . The Examiner's citation in Win, column 2 states, 
"There is a further need for such a mechanism that is easy to configure and re-configure 
as new users and resources become part of the system", again referring to the additive 
data model of Win. The Examiner does not explain how he believes such a data model 
would improve the system of Patel, nor how the use of role-based QoS would "provide a 
more flexible and extensible way to control QoS" in the system of Patel, which does not 
rely on user roles in any of its functions. Applicant asserts that the stated reason to 
combine the references is not commensurate with the features of Patel, and that their 
combination would not result in Applicant's claimed invention. 

When the claim is considered as a whole , the cited art clearly fails to teach or 
suggest a server system receiving a request for service from a client, wherein said 
request includes an encoding specifying a current user role and a requested service and 
in response to receiving the request for service... establishing a quality of service context 
based on the specified current user role included in said request and based on said policy 
data. The Examiner has failed to consider the combination of these limitations in the 
claim as a whole. The Examiner merely submits, in effect, that Patel teaches establishing 
and propagating a QoS context with a transmission packet, that Win teaches including a 
user role in a request for service, and Lupu teaches that QoS statements can be included 
in a role type deflnition. However, these features are not analogous to the elements of 
Applicant's claim that the Examiner submits they teach, and they are not combinable to 
teach or teach or suggest the speciflc features and functionality in the speciflc manner 
combined in Appellants' claim . As noted above, Patel does not teach any use of a user 
role in determining a QoS context. Therefore, there would be no reason to include such 
information in its transmission packets. In addition, the roles cookie of Win does not 
teach or suggest an encoding specifying a current user role. Therefore, even if it were 
included in a packet in Patel, Patel could not use this information (a list of user roles) to 
establish a QoS context for such a packet based on the current user role. In addition, 
there is nothing in Lupu that describes the user of a role type definition (or QoS 
statements thereof ) to establish a QoS context for a request for service, such as the 
request for service recited in Applicant's claim. Therefore, even if the features of Patel, 
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Win, and Lupu could somehow be combined, they would not result in a system in which 
a server system receives a request for service from a client, and the request includes an 
encoding specifying a current user role and a requested service, and in response to 
receiving the request for service... establishing a quality of service context based on the 
specified current user role included in said request and based on said pohcy data. The 
combined art does not teach the combination of these limitations arranged as recited in 
claim 1 when the claim is considered in its entirety. 

For at least the reasons stated above. Applicant asserts that the Examiner has 
failed to establish a prima facie rejection of claim 1. 

Claims 10 and 19 include limitations similar to claim 1, and were rejected for 
similar reasons. Therefore, the arguments presented above apply with equal force to 
these claims, as well. 

Regarding claim 6, the cited art fails to teach or suggest propagating the same 
quality of service context with a subsequent sub-request of said request. The Examiner 
admits that Patel as modified by Win and Lupu does not expressly disclose propagating 
the same quality of service content with a subsequent request, and relies on Zara to teach 
this aspect of Applicant's invention. Specifically, the Examiner cites column 7, lines 58- 
61 of Zara as disclosing attaching the same quality of service context ("tag") with a 
subsequent request related to the first request. Zara is directed to intelligent classification 
and handling of user requests in a data service system. The cited passage (and preceding 
text) states that when a client system generates a first request for a session or transaction, 
the first request does not contain a classification tag . Instead, a classification tag is 
generated by the application system (according to business rules stored in the application 
system ) and is attached to the response to the first request and sent back to the client that 
sent the first request. The requesting client attaches the classification tag that was 
generated and sent with the first response to any subsequent requests for the same session 
or transaction. When the application system receives the subsequent requests, it reapplies 
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the business rules and may re-classify them and attach a different classification tag to the 
corresponding responses (see, e.g., FIG. 3 and its description in columns 8-9). 

Applicant submits that, as described above, Zara does not describe propagating 
the same quality of service context with a subsequent sub-request of (an original) request . 
In fact, Zara does not describe the propagation of classification information from one 
request to another request at all, but from one response to a next request . In addition, 
Zara teaches that for each subsequent request, the business rules are re-evaluated , which 
may result in a different classification for each subsequent request. Therefore, Zara 
clearly does not teach or suggest the above-referenced limitations of Applicant's claim. 

The Examiner submits that it would have been obvious to one of ordinary skill in 
the art to have modified Patel to include Zara's teachings to insure that the requests 
involved in the same session or transaction receive the QoS. However, as noted above, 
Zara does not teach that requests involved in the same session or transaction receive the 
same classification. Instead, in Zara: no classification is included in a first request; 
classifications do not propagate from one request to another request, but from one 
response to a next request; and since business rules are re-evaluated for each request, 
there is nothing to ensure that requests involved in the same session or transaction receive 
the same classification. Therefore, the Examiner's stated motivation to combine the 
references is inconsistent with the teachings of the references themselves. 

For at least the reasons stated above. Applicant asserts that the Examiner has 
failed to establish a prima facie rejection of claim 6. 

Claims 15 and 24 include limitations similar to claim 6, and were rejected for 
similar reasons. Therefore, the arguments presented above apply with equal force to 
these claims, as well. 

Regarding claim 8, the cited art fails to teach or suggest wherein said propagating 
comprises a load balancing service dispatching said request, including said quality of 
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service context, to an application server in a plurality of application servers in the server 
system, based on said quality of service context. The Examiner admits that Patel does not 
expressly disclose a load balancing service that dispatches requests to an application 
server and relies on Vange to teach this aspect of Applicant's invention. Vange is 
directed to a system for load balancing between web servers in a network environment. 
The Examiner submits that Vange discloses a load balancing service that dispatches 
requests to an application server in a plurality of application servers based on a quality of 
service context, citing FIG. 1 of Patel, FIG. 2 of Vange, and paragraph [0094] of Vange. 
Applicant asserts however, that the QoS data used in load balancing in Vange is not a 
QoS context included in a request for service, but is data about current conditions 
collected using other means, such as QoS monitor 64. 

The Examiner submits that it would have been obvious to one of ordinary skill in 
the art to have modified Patel to include Vange 's load balancing capability to insure that 
loads are balanced equally between the servers. Applicant first asserts that Patel includes 
other mechanisms for metering, adaptive congestion control, and flow control that 
facilitate a fair and equitable distribution of packets to virtual groups and to resources 
allocated to those virtual groups that take into account available bandwidth, load, and 
QoS class (see, e.g., FIG, 15, and its description). Therefore, there would be no reason to 
look to Vange for another method of balancing packet distribution, nor is it clear that the 
load balancing of Vange would necessarily improve Patel' s capability to distribute 
packets to virtual groups and their resources. In addition, since Vange 's load balancing 
system does not rely on a QoS context of a particular service request , nor does it 
propagate such a QoS context in a service request to an application server, even if the 
load balancing taught by Vange were incorporated into the system of Patel, the 
combination would not result in Applicant's claimed invention. Instead, it would merely 
add a load balancing function based on monitored performance data to the system of 
Patel. 

For at least the reasons stated above. Applicant asserts that the Examiner has 
failed to establish a prima facie rejection of claim 8. 
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Claims 17 and 26 include limitations similar to claim 8, and were rejected for 
similar reasons. Therefore, the arguments presented above apply with equal force to 
these claims, as well. 

Applicant asserts that numerous other ones of the dependent claims recite further 
distinctions over the cited art. Applicant traverses the rejection of these claims for at 
least the reasons given above in regard to the claims from which they depend. However, 
since the rejections have been shown to be unsupported for the independent claims, a 
further discussion of the dependent claims is not necessary at this time. Applicant 
reserves the right to present additional arguments. 
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CONCLUSION 



Applicant submits the application is in condition for allowance, and an early 
notice to that effect is respectfully requested. 



If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
90800/RCK. 

Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
Attorney for Apphcant 
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